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Port Management to Reduce Logging in Large-Scale NATs 
Abstract 


Various IPv6 transition strategies require the introduction of large- 
scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 
addresses available in the network until transition is complete. 
There has recently been debate over how to manage the sharing of 
ports between different subscribers sharing the same IPv4 address. 
One factor in the discussion is the operational requirement to log 
the assignment of transport addresses to subscribers. It has been 
argued that dynamic assignment of individual ports between 
subscribers requires the generation of an excessive volume of logs. 
This document suggests a way to achieve dynamic port sharing while 
keeping log volumes low. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7768. 
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1. Introduction 


During the IPv6 transition period, some large-scale NAT devices may 
be introduced, e.g., Dual-Stack Lite (DS-Lite), Address Family 
Transition Router (AFTR), and NAT64. When a NAT device needs to set 
up a new connection for a given internal address behind the NAT, it 
needs to create a new mapping entry for the new connection, which 
will contain source IP address, source port or ICMP identifier, 
converted source IP address, converted source port, protocol (TCP/ 
UDP), etc. 


Due to legislation and law enforcement requirement, sometimes it is 
necessary to log these mappings for a period of time, such as 6 
months. The mapping information is highly privacy sensitive; if 
possible, the information should be deleted as soon as possible. 
Some high-performance NAT devices may need to create a large amount 
of new sessions per second. If logs are generated for each mapping 
entry, the log traffic could reach tens of megabytes per second or 
more, which would be a problem for log generation, transmission and 
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storage. According to a test discussed in "Analysis of NAT64 Port 
Allocation Methods for Shared IPv4 Addresses" [ALLOC-METHODS], ina 
network with 20,000 subscribers, over a 60-day period, the raw log 
size can reach 42.5 TB if it is based on per-session log, while the 
log size will be 40.6 GB if it is based on port blocks. Although 
compression technologies can be used before log storage, the log size 
is still big. 


[RFC6888], REQ-13 suggests "maximize port utilization" and REQ-14 
suggests "minimize log volume". However, it is difficult to achieve 
both; there will be a trade-off between the efficiency with which 
ports are used and the rate of generation of log records. 


2. A Suggested Solution 


This document proposes a solution that allows dynamic sharing of port 
ranges between users while minimizing the number of logs that have to 
be generated. Briefly, ports are allocated to the user in blocks. 
Logs are generated only when blocks are allocated or deallocated. 
This provides the necessary traceability while reducing log 
generation by a factor equal to the block size, as compared with 
fully dynamic port allocation. 


This is how the proposal works in greater detail. When the user 
sends out the first packet, a port resource pool is allocated for the 
user, e.g., assigning ports 200172300 of a public IP address to the 
user’s resource pool. Only one log should be generated for this port 
block. When the NAT needs to set up a new mapping entry for the 
user, it can use a port in the user’s resource pool and the 
corresponding public IP address. If the user needs more port 
resources, the NAT can allocate another port block, e.g., ports 
350173800, to the user’s resource pool. Again, just one log needs to 
be generated for this port block. 


[RFC6431] takes this idea further by allocating non-contiguous sets 
of ports using a pseudorandom function. Scattering the allocated 
ports in this way provides a modest barrier to port guessing attacks. 
The use of randomization is discussed further in Section 5. 


Suppose now that a given internal address has been assigned more than 
one block of ports. The individual sessions using ports within a 
port block will start and end at different times. If no ports in 
some port block are used for some configurable time, the NAT can 
remove the port block from the resource pool allocated to a given 
internal address and make it available for other users. In theory, 
it is unnecessary to log deallocations of blocks of ports, because 


Tsou, et al. Informational [Page 3] 


RFC 7768 NATx4 Log Reduction January 2016 


the ports in deallocated blocks will not be used again until the 
blocks are reallocated. However, the deallocation may be logged when 
it occurs adding robustness to troubleshooting or other procedures. 


The deallocation procedure presents a number of difficulties in 
practice. The first problem is the choice of timeout value for the 
block. If idle timers are applied for the individual mappings 
(sessions) within the block, and these conform to the recommendations 
for NAT behavior for the protocol concerned, then the additional time 
that might be configured as a guard for the block as a whole need not 


be more than a few minutes. The block timer in this case serves only 
as a slightly more conservative extension of the individual session 
idle timers. If, instead, a single idle timer is used for the whole 


block, it must itself conform to the recommendations for the protocol 
with which that block of ports is associated. For example, REQ-5 of 
[RFC5382] requires an idle timer expiry duration of at least 2 hours 
and 4 minutes for TCP. 


The next issue with port block deallocation is the conflict between 
the desire to randomize port allocation and the desire to make unused 
resources available to other internal addresses. As mentioned above, 
ideally port selection will take place over the entire set of blocks 
allocated to the internal address. However, taken to its fullest 
extent, such a policy will minimize the probability that all ports in 
any given block are idle long enough for it to be released. 


As an alternative, it is suggested that when choosing which block to 
select a port from, the NAT should omit from its range of choice the 
block that has been idle the longest, unless no ports are available 
in any of the other blocks. The expression "block that has been idle 
the longest" designates the block in which the time since the last 
packet was observed in any of its sessions, in either direction, is 
earlier than the corresponding time in any of the other blocks 
assigned to that internal address. 


3. Issues Of Traceability 


Section 12 of [RFC6269] provides a good discussion of the 
traceability issue. Complete traceability given the NAT-logging 
practices proposed in this document requires that the remote 
destination record the source port of a request along with the source 


address (and presumably protocol, if not implicit). In addition, the 
logs at each end must be timestamped, and the clocks must be 
synchronized within a certain degree of accuracy. Here is one reason 


for the guard timing on block release, to increase the tolerable 
level of clock skew between the two ends. 
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The ability to configure various server applications to record source 
ports has been investigated, with the following results: 


o Source-port recording can be configured in Apache, Postfix, 
sendmail, and sshd. Please refer to the Appendix for the 
configuration guide. 


o Source-port recording is not supported by IIS, Cyrus IMAP, and UW 
IMAP. But it should not be too difficult to get Cyrus IMAP and UW 
IMAP to support it by modifying the source code. 


Where source-port logging can be enabled, this memo strongly urges 


the operators to do so. Similarly, intrusion detection systems 
should capture source port as well as source address of suspect 
packets. 


In some cases [RFC6269], a server may not record the source port of a 
connection. To allow traceability, the NAT device needs to record 
the destination IP address of a connection. As [RFC6269] points out, 
this will provide an incomplete solution to the issue of traceability 
because multiple users of the same shared public IP address may 
access the service at the same time. From the point of view of this 
document, in such situations the game is lost, so to speak, and port 
allocation at the NAT might as well be completely dynamic. 


The final possibility to consider is where the NAT does not do per- 
session logging even given the possibility that the remote end is 
failing to capture source ports. In that case, the port allocation 
policy proposed in this document can be used. The impact on 
traceability is that analysis of the logs would yield only the list 
of all internal addresses mapped to a given public address during the 
period of time concerned. This has an impact on privacy as well as 
traceability, depending on the follow-up actions taken. 


4. Other Considerations 


[RFC6269] notes several issues introduced by the use of dynamic, as 
opposed to static, port assignment. For example, Section 13.2 of 
that document notes the effect on authentication procedures. These 
issues must be resolved, but are not specific to the port allocation 
policy described in this document. 
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Security Considerations 


The discussion that follows addresses an issue that is particularly 
relevant to the proposal made in this document. The security 
considerations applicable to NAT operation for various protocols as 
documented in, for example, [RFC4787] and [RFC5382] also apply to 
this proposal. 


[RFC6056] summarizes the TCP port-guessing attack, by means of which 
an attacker can hijack one end of a TCP connection. One mitigating 
measure is to make the source port number used for a TCP connection 


less predictable. [RFC6056] provides various algorithms for this 
purpose. 
As Section 3.1 of that RFC notes: "...provided adequate algorithms 


are in use, the larger the range from which ephemeral ports are 
selected, the smaller the chances of an attacker are to guess the 
selected port number." Conversely, the reduced range sizes proposed 
by the present document increase the attacker’s chances of guessing 
correctly. This result cannot be totally avoided. However, 
mitigating measures to improve this situation can be taken both at 
port-block assignment time and when selecting individual ports from 
the blocks that have been allocated to a given user. 


At assignment time, one possibility is to assign ports as non- 
contiguous sets of values as proposed in [RFC6431]. However, this 
approach creates a lot of complexity for operations, and the 
pseudorandomization can create uncertainty when the accuracy of logs 
is important to protect someone’s life or liberty. 


Alternatively, the NAT can assign blocks of contiguous ports. 
However, at assignment time, the NAT could attempt to randomize its 
choice of which of the available idle blocks it would assign to a 
given user. This strategy has to be traded-off against the 
desirability of minimizing the chance of conflict between what 
[RFC6056] calls "transport protocol instances" by assigning the most- 
idle block, as suggested in Section 2. A compromise policy might be 
to assign blocks only if they have been idle for a certain amount of 
time, and select pseudorandomly between the blocks available 
according to this criterion. In this case, it is suggested that the 
time value used be greater than the guard timing mentioned in 
Section 2, and that no block should ever be reassigned until it has 
been idle at least for the duration given by the guard timer. 


While the block assignment strategy can provide some mitigation of 
the port-guessing attack, the largest contribution will come from 
pseudorandomization at port-selection time. [RFC6056] provides a 
number of algorithms for achieving this pseudorandomization. When 
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the available ports are contained in blocks, which are not in general 
consecutive, the algorithms clearly need some adaptation. The task 
is complicated by the fact that the number of blocks allocated to the 
user may vary over time. Adaptation is left as an exercise for the 
implementor. 
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Appendix A. Configure Server Software to Log Source Port 


A.1. Apache 


The user can use the LogFormat command to define a customized log 
format and use the CustomLog command to apply that log format. "%a" 
and "S{remote}p" can be used in the format string to require logging 
the client’s IP address and source port, respectively. This feature 
has been available since Apache version 2.1. 


A detailed configuration guide can be found at [APACHE_LOG_CONFIG]. 
A.2. Postfix 

In order to log the client source port, macro 

smtpd_client_port_logging should be set to "yes" in the configuration 


file [POSTFIX_LOG_CONFIG]. 


This feature has been available since Postfix version 2.5. 


A.3. Sendmail 


Sendmail has a macro S${client_port} storing the client port. To log 
the source port, the user can define some check rules. Here is an 
example that should be in the .mc configuration macro 
[SENDMATL_LOG_CONFIG]: 


LOCAL_CONFIG 
Klog syslog 


LOCAL RULESETS 
SLocal_check_mail 
R $* $@ S$(log Port_Stat S$&{client_addr} S$&{client_port} $) 


This feature has been available since version 8.10. 
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A.4. sshd 


SSHD_CONFIG(5) OpenBSD Programmer’s Manual SSHD_CONFIG(5) NAME 
sshd_config - OpenSSH SSH daemon configuration file LoghLevel Gives 
the verbosity level that is used when logging messages from sshd(8). 
The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, 
DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 
are equivalent. DEBUG2 and DEBUG3 each specify higher levels of 
debugging output. Logging with a DEBUG level violates the privacy of 
users and is not recommended. SyslogFacility Gives the facility code 
that is used when logging messages from sshd(8). The possible values 
are: DAEMON, USER, AUTH, LOCALO, LOCAL1, LOCAL2, LOCAL3, LOCAL4, 
LOCAL5, LOCAL6, and LOCAL7. The default is AUTH. 


sshd supports logging the client IP address and client port when a 
client starts connection since version 1.2.2; here is the source code 
in sshd.c: 


verbose ("Connection from %.500s port %d", remote_ip, remote_port); 


sshd supports logging the client IP address when a client disconnects 
in version 1.2.2 to version 5.0. Since version 5.1, sshd supports 
logging the client IP address and source port. Here is the source 
code in sshd.c: 


/* from version 1.2.2 to 5.0*/ 
verbose ("Closing connection to %.100s", remote_ip); 


/* since version 5.1*/ 
verbose ("Closing connection to %.500s port %d", 
remote_ip, remote_port); 


In order to log the source port, the LogLevel should be set to 
VERBOSE [SSHD_LOG_CONFIG] in the configuration file: 


LogLevel VERBOSE 
A.5. Cyrus IMAP and UW IMAP 
Cyrus IMAP and UW IMAP do not support logging the source port for the 


time being. Both software use syslog to create logs; it should not 
be too difficult to get it supported by adding some new code. 
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